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SUMMARY 


The report gives a defining description of the pico subset of the 
programming language Scheme. Scheme is a statically scoped 
and properly tail-recursive dialect of the Lisp programming lan- 
guage [10] invented by Guy Lewis Steele Jr. and Gerald Jay Suss- 
man. It was designed to have exceptionally clear and simple se- 
mantics and few different ways to form expressions. Pico Scheme 
is a purely functional subset of Scheme. 


The introduction offers a brief history of the language and of 
the report. 


The first three chapters present the fundamental ideas of the 
language and describe the notational conventions used for de- 
scribing the language and for writing programs in the language. 
Chapters and [5] describe the syntax and semantics of expres- 
sions, definitions, and programs. 

Chapter|6|describes Scheme’s built-in procedures, which include 
all of the language’s data manipulation primitives. 

Chapter |7| provides a formal syntax for Scheme written in ex- 
tended BNF, along with a formal denotational semantics. Ex- 
amples of the use of the language follow the formal syntax and 
semantics. 

The report concludes with references and an index. 


Note: The editors of the R’RS, R°RS and R°RS reports are listed 
as authors of this report in recognition of the substantial portions 
of this report that are copied directly from R°RS, R°RS and R’RS. 
There is no intended implication that those editors, individually or 
collectively, support or do not support this report. 
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Background 


The first description of Scheme was written in 1975 [22]. A 
revised report [17] appeared in 1978, which described the evolu- 
tion of the language as its MIT implementation was upgraded to 
support an innovative compiler [18]. An introductory computer 
science textbook using Scheme was published in 1984 [i]. 
Fifteen representatives of the major implementations of Scheme 
met in October 1984. Their report, the RRRS [4], was pub- 
lished at MIT and Indiana University in the summer of 1985. 
Further revision took place in the spring of 1986, resulting in 
the R3RS [15]. Work in the spring of 1988 resulted in R*RS [5], 
which became the basis for the IEEE Standard for the Scheme 
Programming Language in 1991 [8]. In 1998, several additions to 
the IEEE standard, including high-level hygienic macros, mul- 
tiple return values, and eval, were finalized as the R°RS [9]. 
In the fall of 2006, work began on a more ambitious standard. 
The resulting standard, the R°RS, was completed in August 
2007 {I9]. 

In 2009 the Scheme Steering Committee decided to divide the 
standard into two separate but compatible languages — a “small” 
language and a “large” language. The “small” language of that 
effort resulted in R’RS [20]. The development of Pico Scheme 
took place in a git repository{I3] and is not an official Scheme 
Report. 
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INTRODUCTION 


Programming languages should be designed not by piling fea- 
ture on top of feature, but by removing the weaknesses and re- 
strictions that make additional features appear necessary. Pico 
Scheme continues this tradition by creating a smaller subset 
of R’RS that can be easily implemented and understood, yet 
remains a full programming language. Features including side 
effects and continuations that add complication to both the de- 
notational semantics and the implementation are removed. In 
this report R’RS is used to refer to the “small” language. 


We intend this report to belong to the entire Scheme community, 
and so we grant permission to copy it in whole or in part without 
fee. In particular, we encourage implementers of Pico Scheme 
to use this report as a starting point for manuals and other 
documentation, modifying it as necessary. 
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DESCRIPTION OF THE LANGUAGE 


1. Overview of Scheme 
1.1. Semantics 


This section gives an overview of Scheme’s semantics. A detailed 
informal semantics is the subject of chapters [3] through [6] For 
reference purposes, section provides a formal semantics of 
Pico Scheme. 

Scheme is a statically scoped programming language. Each use 
of a variable is associated with a lexically apparent binding of 
that variable. 

Scheme is a dynamically typed language. Types are associ- 
ated with values (also called objects) rather than with vari- 
ables. Statically typed languages, by contrast, associate types 
with variables and expressions as well as with values. 

All objects created in the course of a Scheme computation, in- 
cluding procedures, have unlimited extent. No Scheme object is 
ever destroyed. The reason that implementations of Scheme do 
not (usually!) run out of storage is that they are permitted to 
reclaim the storage occupied by an object if they can prove that 
the object cannot possibly matter to any future computation. 
Scheme procedures are objects in their own right. Procedures 
can be created dynamically, stored in data structures, returned 
as results of procedures, and so on. 

Arguments to Scheme procedures are always passed by value, 
which means that the actual argument expressions are evaluated 
before the procedure gains control, regardless of whether the 
procedure needs the result of the evaluation. 
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Pico Scheme’s model of arithmetic is simplified compared to 
R’RS and only integers are required. 


1.2. Syntax 


Scheme, like most dialects of Lisp, employs a fully parenthesized 
prefix notation for programs and other data; the grammar of 
Scheme generates a sublanguage of the language used for data. 
An important consequence of this simple, uniform representa- 
tion is that Scheme programs and data can easily be treated 
uniformly by other Scheme programs. 

The formal syntax of Scheme is described in section [7.1] 


1.2.1. Base and optional features 


Pico Scheme is already reduced, but if a smaller subset is de- 
sired, either symbols or integers could be removed. Either cond 
or if could be removed. Both let and apply could be re- 
moved. If only a REPL is provided, output could be removed. 
If extended, we suggest using R’RS as a guide. For cases where 
both R’RS and Pico Scheme are using defined behavior, it is 
intended that Pico Scheme should have identical results. 


1.2.2. Error situations and unspecified behavior 


When speaking of an error situation, this report uses the phrase 
“an error is signaled” to indicate that implementations must 
detect and report the error. 
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If such wording does not appear in the discussion of an error, 
then implementations are not required to detect or report the 
error, though they are encouraged to do so. 

If the value of an expression is said to be “unspecified,” then 
the expression must evaluate to some object without signaling 
an error, but the value depends on the implementation; this 
report explicitly does not say what value is returned. 

Finally, the words and phrases “must,” “must not,” “shall,” 
“shall not,” “should,” “should not,” “may,” “required,” “rec- 
ommended,” and “optional,” although not capitalized in this 
report, are to be interpreted as described in RFC 2119 [2]. They 
are used only with reference to implementer or implementation 
behavior, not with reference to programmer or program behav- 
ior. 


1.2.3. Entry format 


Chapters [4] and [6] are organized into entries. Each entry de- 
scribes one language feature or a group of related features, where 
a feature is either a syntactic construct or a procedure. An entry 
begins with one or more header lines of the form 

template category 
for identifiers in the base language. 

If category is “syntax,” the entry describes an expression type, 
and the template gives the syntax of the expression type. Com- 
ponents of expressions are designated by syntactic variables, 
which are written using angle brackets, for example (expression) 
and (variable). Syntactic variables are intended to denote seg- 
ments of program text; for example, (expression) stands for any 
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string of characters which is a syntactically valid expression. 
The notation 


indicates zero or more occurrences of a (thing), and 


(thing) (things) ain 


indicates one or more occurrences of a (thing). 

If category is “auxiliary syntax,” then the entry describes a syn- 
tax binding that occurs only as part of specific surrounding ex- 
pressions. Any use as an independent syntactic construct or 
variable is an error. 

If category is “procedure,” then the entry describes a procedure, 
and the header line gives a template for a call to the procedure. 
Argument names in the template are italicized. Thus the header 
line 

(car pair) procedure 
indicates that the procedure bound to the car variable takes 
one argument, a pair (see below). The header lines 

(- n) procedure 
(- ni nz) procedure 
indicate that the - procedure must be defined to take either one 
or two arguments. 

It is an error for a procedure to be presented with an argument 
that it is not specified to handle. For succinctness, we follow 
the convention that if an argument name is also the name of a 
type listed in section then it is an error if that argument 
is not of the named type. For example, the header line for car 


1. Overview of Scheme 13 


given above dictates that the only argument to car is a pair. 
The following naming conventions also imply type restrictions: 


boolean boolean value (#t or #£) 
list, list), ... list;,... list (see ction 

N, N1,... Nj, --- integer 

obj any object 

pair pair 

proc procedure 

symbol symbol 


1.2.4. Evaluation examples 


The symbol “=>” used in program examples is read “evaluates 
o.” For example, 


(* 5 8) = 40 


means that the expression (* 5 8) evaluates to the object 40. 
Or, more precisely: the expression given by the sequence of 
characters “(+ 5 8)” evaluates, in the initial environment, to 
an object that can be represented externally by the sequence 
of characters “40.” See section B.3] for a discussion of external 
representations of objects. 


1.2.5. Naming conventions 


By convention, ? is the final character of the names of procedures 
that always return a boolean value. Such procedures are called 
predicates. Predicates, like all procedures in Pico Scheme, are 
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generally side-effect free, except that they may have an error 
when passed the wrong type of argument. 


2. Lexical conventions 
This section gives an informal account of some of the lexical 
conventions used in writing Scheme programs. For a formal 
syntax of Scheme, see section [7.1] 


2.1. Identifiers 


An identifier is any sequence of letters, digits, and “extended 
identifier characters” provided that it does not have a prefix 
which is a valid number. However, the . token (a single period) 
used in the list syntax is not an identifier. 
All implementations of Scheme must support the following ex- 
tended identifier characters: 

'$ReExe+- . fr <=> 77 _” 


Here are some examples of identifiers: 


re 
+soup+ <=? 

->string a34kTMNs 
lambda list->vector 
q Viva 


the-word-recursion-has-many-meanings 


See section for the formal syntax of identifiers. 
Identifiers have two uses within Scheme programs: 
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e Any identifier can be used as a variable or as a syntactic 
keyword (see section|3.1). 


e When an identifier appears as a literal or within a literal 
(see section|4.1.2), it is being used to denote a symbol (see 


section (6.5). 


In contrast with earlier revisions of the report [9], the syntax 
distinguishes between upper and lower case in identifiers and 
in characters specified using their names. None of the identi- 
fiers defined in this report contain upper-case characters, even 
when they appear to do so as a result of the English-language 
convention of capitalizing the first word of a sentence. 


2.2. Whitespace and comments 


Whitespace characters include the space, tab, and newline char- 
acters. (Implementations may provide additional whitespace 
characters such as page break.) Whitespace is used for improved 
readability and as necessary to separate tokens from each other, 
a token being an indivisible lexical unit such as an identifier or 
number, but is otherwise insignificant. Whitespace can occur 
between any two tokens, but not within a token. 

The lexical syntax includes one comment form. Comments are 
treated exactly like whitespace. 

A semicolon (;) indicates the start of a line comment. The 
comment continues to the end of the line on which the semicolon 
appears. 
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2.3. Other notations 


For a description of the notations used for numbers, see sec- 
tion 


. + - These are used in numbers, and can also occur anywhere 
in an identifier. A delimited plus or minus sign by itself 
is also an identifier. Note that a sequence of two or more 
periods zs an identifier. 


( ) Parentheses are used for grouping and to notate lists (sec- 
tion |6.4). 
? The apostrophe (single quote) character is used to indicate 


literal data (section |4.1.2). 


C ] { } Left and right square and curly brackets (braces) are 
reserved for possible future extensions to the language. 


, ,@ " | \ The grave accent, character comma and sequence 
comma, at-sign, quotation mark, vertical line, and back- 
slash are used by R’RS. 


#t #£ These are the boolean constants (section |6.3). 


3. Basic concepts 
3.1. Variables, syntactic keywords, and regions 


An identifier can name either a type of syntax or a value. An 
identifier that names a type of syntax is called a syntactic key- 
word and is said to be bound to a transformer for that syntax. 


3. Basic concepts 17 


An identifier that names a value is called a variable and is said 
to be bound to that value. The set of all visible bindings in 
effect at some point in a program is known as the environment 
in effect at that point. The value to which a variable is bound 
is called the variable’s value. In R’RS variables are technically 
bound to a memory location instead of a value. Pico Scheme 
implementations may bind variables to values. 


Certain expression types bind variables to values. These expres- 
sion types are called binding constructs. 


The most fundamental of the variable binding constructs is the 
lambda expression, because all other variable binding constructs 
can be explained in terms of lambda expressions. The other 
variable binding constructs are let and define. 


Scheme is a language with block structure. To each place where 
an identifier is bound in a program there corresponds a region 
of the program text within which the binding is visible. The 
region is determined by the particular binding construct that 
establishes the binding; if the binding is established by a lambda 
expression, for example, then its region is the entire lambda 
expression. Every mention of an identifier refers to the binding 
of the identifier that established the innermost of the regions 
containing the use. If there is no binding of the identifier whose 
region contains the use, then the use refers to the binding for 
the variable in the global environment, if any (chapters|4]and|6); 
if there is no binding for the identifier, it is said to be unbound. 
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3.2. Disjointness of types 


No object satisfies more than one of the following predicates: 


boolean? null? 
number? pair? 
procedure? symbol? 


These predicates define the types boolean, the empty list object, 
number, pair, procedure, and symbol. 

Although there is a separate boolean type, any Scheme value 
can be used as a boolean value for the purpose of a conditional 
test. As explained in section[6.3} all values count as true in such 
a test except for #f. This report uses the word “true” to refer 
to #t and any Scheme value except #f, and the word “false” to 
refer to #£. 


3.3. External representations 


An important concept in Scheme (and Lisp) is that of the ex- 
ternal representation of an object as a sequence of characters. 
For example, an external representation of the integer 28 is the 
sequence of characters “28”, and an external representation of 
a list consisting of the integers 8 and 13 is the sequence of char- 
acters “(8 13)”. 

The external representation of an object is not necessarily unique. 
The integer 28 also has a representation “+28”, and the list in 
the previous paragraph also has the representations “( 08 13 


)” and “(8 . (13 . ()))” (see section 6.4). 
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Many objects have standard external representations, but some, 
such as procedures, do not have standard representations (al- 
though particular implementations may define representations 
for them). 


An external representation can be written in a program to ob- 
tain the corresponding object (see quote, section |4.1.2). 


Note that the sequence of characters “(+ 2 6)” is not an ex- 
ternal representation of the integer 8, even though it is an ex- 
pression evaluating to the integer 8; rather, it is an external 
representation of a three-element list, the elements of which are 
the symbol + and the integers 2 and 6. Scheme’s syntax has 
the property that any sequence of characters that is an expres- 
sion is also the external representation of some object. This can 
lead to confusion, since it is not always obvious out of context 
whether a given sequence of characters is intended to denote 
data or program, but it is also a source of power, since it facili- 
tates writing programs such as interpreters and compilers that 
treat programs as data (or vice versa). 


The syntax of external representations of various kinds of ob- 
jects accompanies the description of the primitives for manipu- 
lating the objects in the appropriate sections of chapter [6] 


3.4. Storage model 


Since side effects are not allowed, implementations may choose 
to use any convenient storage model. 
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3.5. Proper tail recursion 


Implementations of Scheme are required to be properly tail- 
recursive. Procedure calls that occur in certain syntactic con- 
texts defined below are tail calls. A Scheme implementation is 
properly tail-recursive if it supports an unbounded number of 
active tail calls. A call is active if the called procedure might 
still return. Calls can return at most once and the active calls 
are those that have not yet returned. A formal definition of 
proper tail recursion can be found in [3]. 

Rationale: 

Intuitively, no space is needed for an active tail call because the 
continuation that is used in the tail call has the same semantics as the 
continuation passed to the procedure containing the call. Although 
an improper implementation might use a new continuation in the call, 
a return to this new continuation would be followed immediately by 
a return to the continuation passed to the procedure. A properly 
tail-recursive implementation returns to that continuation directly. 
Proper tail recursion was one of the central ideas in Steele and Suss- 
man’s original version of Scheme. Their first Scheme interpreter im- 
plemented both functions and actors. Control flow was expressed 
using actors, which differed from functions in that they passed their 
results on to another actor instead of returning to a caller. In the 
terminology of this section, each actor finished with a tail call to 
another actor. 

Steele and Sussman later observed that in their interpreter the code 
for dealing with actors was identical to that for functions and thus 
there was no need to include both in the language. 

A tail callis a procedure call that occurs in a tail context. Tail 
contexts are defined inductively. Note that a tail context is al- 
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ways determined with respect to a particular lambda expression. 


e The last expression within the body of a lambda expres- 
sion, shown as (tail expression) below, occurs in a tail con- 
text. 


(lambda (formals) 
(definition)* (tail expression) ) 


e If one of the following expressions is in a tail context, then 
the subexpressions shown as (tail expression) are in a tail 
context. These were derived from rules in the grammar 
given in chapter[7]by replacing some occurrences of (body) 
with (tail body), and some occurrences of (expression) 
with (tail expression). Only those rules that contain tail 
contexts are shown here. 


(if (expression) (tail expression) (tail expression) ) 
(if (expression) (tail expression) ) 


(cond (cond clause) +) 
(cond (cond clause)* (else (tail expression) )) 


(and (expression)* (tail expression) ) 
(or (expression)* (tail expression) ) 


(let ((binding spec)*) (tail body)) 
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where 
(cond clause) —+> ((test) (tail expression) ) 


(tail body) —> (definition)* (tail expression) 


In addition, the first argument passed to apply must be called 
via a tail call. 

In the following example the only tail call is the call to £. None 
of the calls to g or h are tail calls. The reference to x is in a tail 
context, but it is not a call and thus is not a tail call. 


(lambda () 
(if (g) 
(let ((x (h))) 
x) 
(and (g) (£)))) 


Note: Implementations may recognize that some non-tail calls, such 
as the call to h above, can be evaluated as though they were tail calls. 
In the example above, the let expression could be compiled as a tail 
call to h. 


4. Expressions 

Expression types are categorized as primitive or derived. Primi- 
tive expression types include variables and procedure calls. De- 
rived expression types are not semantically primitive, but can 
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instead be explained in terms of the primitive constructs as in 
section 


4.1. Primitive expression types 


4.1.1. Variable references 


(variable) syntax 
An expression consisting of a variable (section|3.1) is a variable 
reference. The value of the variable reference is the value stored 
in the variable. It is an error to reference an unbound variable. 


(define x 28) 
x = 28 


4.1.2. Literal expressions 


(quote (datum)) syntax 
? (datum) syntax 
(constant) syntax 


(quote (datum)) evaluates to (datum). (Datum) can be any 
external representation of a Scheme object (see section |3.3). 
This notation is used to include literal constants in Scheme 
code. 


(quote a) — a 
(quote (a b c)) = (abc) 
(quote (+ 1 2)) => (¢ 1 2) 


(quote (datum)) can be abbreviated as ’(datum). The two 
notations are equivalent in all respects. 
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"a = a 

?(a bc) = (abc) 
0 => 0 

?(+ 1 2) = (+ 1 2) 

> (quote a) = > (quote a) 
a = > (quote a) 


Numerical constants and boolean constants evaluate to them- 
selves; they need not be quoted. 


7145932 => 145932 
145932 => 145932 
Ht => Ft 
#t => Ft 
4.1.3. Procedure calls 
((operator) (operand;) ...) syntax 


A procedure call is written by enclosing in parentheses an ex- 
pression for the procedure to be called followed by expressions 
for the arguments to be passed to it. The operator and operand 
expressions are evaluated (in an unspecified order) and the re- 
sulting procedure is passed the resulting arguments. 


(+ 3 4) = 7 
(Cif #£ + *) 3 4) = 12 


A number of procedures are available as the values of variables 
in the initial environment. For example, the addition and mul- 
tiplication procedures in the above examples are the values of 
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the variables + and *. New procedures are created by evaluating 
lambda expressions (see section [4.1.4). 

Procedure calls in Pico Scheme return one value. 

Note: In contrast to other dialects of Lisp, the order of evaluation is 
unspecified, and the operator expression and the operand expressions 
are always evaluated with the same evaluation rules. Because Pico 
Scheme procedures do not have side effects, the order of evaluation 
does not affect results. 

Note: Although the order of evaluation is otherwise unspecified, 
the effect of any concurrent evaluation of the operator and operand 
expressions is constrained to be consistent with some sequential order 
of evaluation. The order of evaluation may be chosen differently for 
each procedure call. 

Note: In many dialects of Lisp, the empty list, (), is a legitimate 
expression evaluating to itself. In Scheme, the expression () is an 
error, however (quote ()) can be used. 


4.1.4. Procedures 


(lambda (formals) (body)) syntax 
Syntax: (Formals) is a formal arguments list as described below, 
and (body) is a sequence of zero or more definitions followed by 
one expression. 

Semantics: A lambda expression evaluates to a procedure. The 
environment in effect when the lambda expression was evaluated 
is remembered as part of the procedure. When the procedure 
is later called with some actual arguments, the environment in 
which the lambda expression was evaluated will be extended by 
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binding the variables in the formal argument list to the cor- 
responding actual argument values. Next, the definitions and 
expression in the body of the lambda expression will be evalu- 
ated sequentially in the extended environment. The results of 
the expression in the body will be returned as the results of the 
procedure call. 


(lambda (x) (+ x x)) => a procedure 
((lambda (x) (+ x x)) 4) = 8 


(define reverse-subtract 
(lambda (x y) (- y x))) 
(reverse-subtract 7 10) => 3 


(define add4 
(let ((x 4)) 
(lambda (y) (+ x y)))) 
(add4 6) = 10 


(Formals) have one of the following forms: 


e ((variable;) ...): The procedure takes a fixed number of 
arguments; when the procedure is called, the arguments 
will be bound to the corresponding variables. 


e (variable): The procedure takes any number of arguments; 
when the procedure is called, the sequence of actual argu- 
ments is converted into a newly allocated list, and the list 
is bound to (variable). 


It is an error for a (variable) to appear more than once in 
(formals). 
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((lambda x x) 3 4 5 6) = (345 6) 


4.1.5. Conditionals 


(if (test) (consequent) (alternate) ) syntax 
(if (test) (consequent) ) syntax 
Syntax: (Test), (consequent), and (alternate) are expressions. 
Semantics: An if expression is evaluated as follows: first, (test) 
is evaluated. If it yields a true value (see section (6.3), then 
(consequent) is evaluated and its values are returned. Otherwise 
(alternate) is evaluated and its values are returned. If (test) 
yields a false value and no (alternate) is specified, then the result 
of the expression is unspecified. 


(if (> 3 2) ’yes ’no) = yes 
(if (> 2 3) ’yes ’no) = no 
(if (> 3 2) 

(- 3 2) 

(+ 3 2)) => 1 


4.2. Derived expression types 


The constructs in this section can be created via rewrite rules 
with the primitive constructs described in the previous section. 
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4.2.1. Conditionals 


(cond (clause;) (clauseg) ...) syntax 
else auxiliary syntax 
Syntax: (Clauses) take one form 


((test) (expression) ) 


where (test) is any expression. The last (clause) can be an “else 
clause,” which has the form 


(else (expression)). 


Semantics: A cond expression is evaluated by evaluating the 

(test) expressions of successive (clause)s in order until one of 

them evaluates to a true value (see section [6.3). When a (test) 

evaluates to a true value, the remaining (expression) in its (clause) 
is evaluated, and the result of the (expression) in the (clause) 

are returned as the results of the entire cond expression. 

If all (test)s evaluate to #£, and there is no else clause, then the 

result of the conditional expression is unspecified; if there is an 

else clause, then its (expression) is evaluated, and the value of 

it is returned. 


(cond ((> 3 2) ’greater) 

((< 3 2) ’less)) = greater 
(cond ((> 3 3) ’greater) 

((< 3 3) ’less) 

(else ’equal)) => equal 
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(and (test;) ...) syntax 
Semantics: The (test) expressions are evaluated from left to 
right, and if any expression evaluates to #£ (see section|6.3), then 
#f is returned. Any remaining expressions are not evaluated. If 
all the expressions evaluate to true values, the value of the last 
expression is returned. If there are no expressions, then #t is 
returned. 


(and (= 2 2) (> 2 1)) = #t 
(and (= 2 2) (< 2 1)) = Ff 
(and 12 ’c ’(f g)) = (f g) 
(and) => #t 
(or (testy) ...) syntax 


Semantics: The (test) expressions are evaluated from left to 
right, and the value of the first expression that evaluates to a 
true value (see section 6.3) is returned. Any remaining expres- 
sions are not evaluated. If all expressions evaluate to #f or if 
there are no expressions, then #f is returned. 


(or (= 2 2) © 2 1)) = #t 
(or (= 2 2) (««K 2 1)) = #t 
(or #£ #£ #f) => #f 
(or ’?(b c) (car ’a)) => (bc) 


4.2.2. Binding constructs 


The binding construct let gives Scheme a block structure, like 
Algol 60. In a let expression, the initial values are computed 
before any of the variables become bound. 
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(let (bindings) (body)) syntax 
Syntaz: (Bindings) has the form 


(((variable1) (initi)) ...), 


where each (init) is an expression, and (body) is a sequence of 
zero or more definitions followed by one expression as described 
in section It is an error for a (variable) to appear more 
than once in the list of variables being bound. 

Semantics: The (init)s are evaluated in the current environment 
(in some unspecified order), the (variable)s are bound to the 
results, the (body) is evaluated in the extended environment, 
and the values of the last expression of (body) are returned. 
Each binding of a (variable) has (body) as its region. 


(let ((x 2) (y 3)) 
(* x y)) => 6 


(let ((x 2) (y 3)) 
(let ((x 7) 
(z (+ x y))) 
(* z x))) => 35 


5. Program structure 
5.1. Programs 


A Scheme program consists of a sequence of expressions, def- 
initions, and output. Expressions are described in chapter 
Definitions are variable definitions which are explained in this 
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chapter. They are valid in the outermost level of a (program) 
and at the beginning of a (body). 

Expressions occurring at the outermost level of a program do 
not create any bindings. They are executed in order when the 
program is invoked or loaded, and typically perform some kind 
of initialization. 

Programs are typically stored in files, although in some im- 
plementations they can be entered interactively into a running 
Scheme system. Other paradigms are possible. 

Note: In order to simplify Pico Scheme, library declarations and im- 
porting are not part of the specification and not required. However, 
R’RS requires that programs start with one or more import declara- 
tions. Pico Scheme programs being run by R’RS will need to have a 
(import (scheme base) (scheme write)) added at the start. 

Pico Scheme implementations may choose to implement R’RS import, 
define-library, and export directly as declarations. A possible al- 
ternative implementation is adding a variables declaration (such as 
define-vars) that uses the auxiliary function extends and appropri- 
ate rewrite rules to map import to define-vars. 


5.2. Variable definitions 


A variable definition binds one identifier and specifies a value 
for it. The only kind of variable definition takes the following 
form: 


e (define (variable) (expression) ) 


Note that if (expression) is a lambda expression, it is evaluated 
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in an environment that includes the defined (variable) so it can 
be used for recursion. 


5.2.1. Top level definitions 
At the outermost level of a program, a definition 
(define (variable) (expression) ) 


adds or updates the environment with the new assignment. 


(define add3 
(lambda (x) (+ x 3))) 


(add3 3) —» 6 
(define first car) 
(first ’(1 2)) => 1 


5.2.2. Internal definitions 


Definitions can occur at the beginning of a (body) (that is, the 
body of a lambda or let). Such definitions are known as in- 
ternal definitions as opposed to the global definitions described 
above. The variables defined by internal definitions are local 
to the (body). That is, (variable) is bound, and the region of 
the binding is the following definitions and expressions in the 
(body). For example, 


(let ((x 5)) 
(define bar (lambda (a b) (+ (* a b) a))) 
(define foo (lambda (y) (bar x y))) 
(foo (+ x 3))) => 45 
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In R’RS it is an error to define the same identifier more than 
once in the same (body). 

Note: Unlike R’RS, in Pico scheme, the region binding of a defini- 
tions is the following definitions and expressions in the (body), not 
the entire (body) due to differences in semantics from the removal of 
set!. 


5.3. The REPL 


Implementations may provide an interactive session called a 
REPL (Read-Eval-Print Loop), where expressions and defini- 
tions can be entered and evaluated one at a time. 

An implementation may provide a mode of operation in which 
the REPL reads its input from a file. 


6. Standard procedures 

This chapter describes Scheme’s built-in procedures. 

A program can use a global variable definition to bind any vari- 
able. These operations do not modify the behavior of any pro- 
cedure defined in this report. 


6.1. Equivalence predicates 


A predicate is a procedure that always returns a boolean value 
(#t or #£). An equivalence predicate is the computational ana- 
logue of a mathematical equivalence relation; it is symmetric, 
reflexive, and transitive. 
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Ceqv? obj, obj2) procedure 
The eqv? procedure can determine if symbols, numbers and 
booleans are equivalent. The empty list is only equivalent to 
another empty list. Two different types are never equivalent, 
and other comparisons are unspecified. 

The eqv? procedure returns #t if: 


e obj, and obj2 are both #t or both #f. 


e obj, and objz are both symbols and are the same symbol 


(section 6.5). 


e obj, and 0672 are both numbers and are numerically equal 
(in the sense of =). 


e obj, and obj. are both the empty list. 

The eqv? procedure returns #f if: 
e obj, and obj. are of different types (section [3.2). 
e one of 067; and obj, is #t but the other is #f. 


e obj, and obj. are symbols but are not the same symbol 


(section (6.5). 


e obj, and obj. are both numbers and are numerically un- 
equal (in the sense of =). 


e one of 067, and obj. is the empty list but the other is not. 
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(eqv? ’a ’a) = #t 
(eqv? ’a ’b) = #f 
(eqv? ’(a) ’(a)) => unspecified 
(eqv? (list ’a) (list ’a)) = > unspecified 
(eqv? ?() ’Q) —= HH 
(eqv? 2 2) = #t 
(eqv? car car) => unspecified 
(let ((n (+ 2 3))) 

(eqv? n n)) => #t 
(let ((x ’(a))) 

(eqv? x x)) => unspecified 
(let (Cx ?Q)) 

(eqv? x x)) => #t 
(let ((p (lambda (x) x))) 

(eqv? p p)) => unspecified 
(eqv? #£ ’nil) = #f 


Rationale: eqv? can be used to compare simple values, and most 
other uses are left unspecified. 


6.2. Numbers 


It is important to distinguish between mathematical numbers, 
the Scheme numbers that attempt to model them, the machine 
representations used to implement the Scheme numbers, and 
notations used to write numbers. This report uses the types 
number, and integer to refer to both mathematical numbers and 
Scheme numbers. 

Pico Scheme implementations should support signed integers 
with a range that includes the longest possible list length. 
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Note: Pico Scheme implementations may support integers of prac- 
tically unlimited size, or they may support integers with a limited 
range. If using limited range integers some operations may overflow. 
Pico Scheme implementations should document integer range restric- 
tions and how they are handled. Pico Scheme implementations may 
either return the wrapped around number, or return a miscellaneous 
value (such as false or undefined) for overflow (which can be checked 
with number? which will return #f for a miscellaneous value). 


6.2.1. Syntax of numerical constants 


The syntax of the written representations for numbers is de- 
scribed formally in section Numbers are written in deci- 
mal. 


6.2.2. Numerical operations 


The reader is referred to section for a summary of the 
naming conventions used to specify restrictions on the types of 
arguments to numerical routines. 


(number? obj) procedure 
This numerical type predicate can be applied to any kind of 
argument, including non-numbers. It returns #t if the object is 
a number, and otherwise it returns #f. 


(number? 3) = #t 
(number? ’(1)) = #f 
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(= ny nz) procedure 
(< ny ne) procedure 
(> ny ne) procedure 


These procedures return #t if their arguments are (respectively): 
equal, monotonically increasing, monotonically decreasing, and 
#f otherwise. 

These predicates are required to be transitive. 


(+ ni ne) procedure 
(* ny N2) procedure 


These procedures return the sum or product of their arguments. 


(+ 3 4) => 7 

(* 4 5) = 20 
(- n) procedure 
(- ny no) procedure 


With two arguments, this procedure returns the difference of its 
arguments, associating to the left. With one argument, however, 
it returns the additive inverse of its argument. 


(- 3 4) => -1 
(- 3) = -3 
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6.3. Booleans 


The standard boolean objects for true and false are written as 
#t and #£. What really matters, though, are the objects that 
the Scheme conditional expressions (if, cond, and, or) treat 
as true or false. The phrase “a true value” (or sometimes just 
“true”) means any object treated as true by the conditional 
expressions, and the phrase “a false value” (or “false”) means 
any object treated as false by the conditional expressions. 

Of all the Scheme values, only #£ counts as false in conditional 
expressions. All other Scheme values, including #t, count as 
true. 

Note: Unlike some other dialects of Lisp, Scheme distinguishes #f 
and the empty list from each other and from the symbol nil. 
Boolean constants evaluate to themselves, so they do not need 
to be quoted in programs. 


#t —_~=—s«FL 
#f —= “ff 
HL — “tf 
(not obj) procedure 


The not procedure returns #t if 007 is false, and returns #f 
otherwise. 


(not #t) = #f 
(not 3) — #f 
(not ’(3)) => #f 
(not #£) => #t 
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(not ’()) = # 
(not ’nil) = #f 
(boolean? obj) procedure 


The boolean? predicate returns #t if obj is either #t or #£ and 
returns #f£ otherwise. 


(boolean? #f) = #t 
(boolean? 0) = #f 
(boolean? ’()) = Ff 


6.4. Pairs and lists 


A pair (sometimes called a dotted pair) is a record structure with 
two fields called the car and cdr fields (for historical reasons). 
Pairs are created by the procedure cons. The car and cdr fields 
are accessed by the procedures car and cdr. 

Pairs are used primarily to represent lists. A list can be defined 
recursively as either the empty list or a pair whose cdr is a list. 
More precisely, the set of lists is defined as the smallest set X 
such that 


e The empty list is in X. 


e If list is in X, then any pair whose cdr field contains list 
is also in X. 
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The objects in the car fields of successive pairs of a list are the 
elements of the list. For example, a two-element list is a pair 
whose car is the first element and whose cdr is a pair whose 
car is the second element and whose cdr is the empty list. The 
length of a list is the number of elements, which is the same as 
the number of pairs. 

The empty list is a special object of its own type. It is not a 
pair, it has no elements, and its length is zero. 

Note: The above definitions imply that all lists have finite length 
and are terminated by the empty list. 

The most general notation (external representation) for Scheme 
pairs is the “dotted” notation (c; . ca) where c, is the value of 
the car field and cp is the value of the cdr field. For example (4 
. 5) is a pair whose car is 4 and whose cdr is 5. Note that (4 
. 5) is the external representation of a pair, not an expression 
that evaluates to a pair. 

A more streamlined notation can be used for lists: the elements 
of the list are simply enclosed in parentheses and separated by 
spaces. The empty list is written (). For example, 


(abcde) 
and 
(a. (b. (ec . (d. Ce. —))))) 


are equivalent notations for a list of symbols. 

A chain of pairs not ending in the empty list is called an improper 
last. Note that an improper list is not a list. The list and dotted 
notations can be combined to represent improper lists: 
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(abc. d) 
is equivalent to 
(a. (b. (c . d))) 


Whether a given pair is a list depends upon what is stored in 
the cdr field. 

Within literal expressions and representations of objects the 
form ’ (datum) denotes a two-element list whose first elements is 
the symbols quote. The second element in each case is (datum). 
This convention is supported so that arbitrary Scheme programs 
can be represented as lists. That is, according to Scheme’s gram- 
mar, every (expression) is also a (datum) (see section[7.1.2). See 
section 


(pair? obj) procedure 
The pair? predicate returns #t if obj is a pair, and otherwise 
returns #f£. 


(pair? ’(a . b)) = #t 
(pair? ’(a b c)) = #t 
(pair? ’()) => #f 
(cons obj; obj2) procedure 


Returns a pair whose car is 0bj, and whose cdr is 0bj2. 
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(cons ’a ’()) => (a) 
(cons ’(a) ’(b c d)) = ((a) bc d) 
(cons ’a 3) = (a. 3) 
(cons ’?(a b) ’c) = ((ab). oc) 
(car pair) procedure 


Returns the contents of the car field of pair. Note that it is an 
error to take the car of the empty list. 


(car ’(a b c)) => a 
(car ’?((a) bc d)) => (a) 
(car ’?(1 . 2)) => 1 
(car ’?Q)) = error 
(cdr pair) procedure 


Returns the contents of the cdr field of pair. Note that it is an 
error to take the cdr of the empty list. 


(cdr ’((a) bc d)) = (bc d) 
(cdr ’?(1 . 2)) =— 2 
(cdr ’?()) => error 
(null? obj) procedure 


Returns #t if obj is the empty list, otherwise returns #f. 
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6.5. Symbols 


Symbols are objects whose usefulness rests on the fact that two 
symbols are identical (in the sense of eqv?) if and only if their 
names are spelled the same way. For instance, they can be used 
the way enumerated values are used in other languages. 

The rules for writing a symbol are exactly the same as the rules 


for writing an identifier; see sections [2.1] and 


(symbol? obj) procedure 
Returns #t if 0b7 is a symbol, otherwise returns #f. 


(symbol? ’foo) = #t 
(symbol? (car ’(a b))) => #t 
(symbol? ’nil) => #t 
(symbol? ’()) = #f 
(symbol? #f) = Ff 
6.6. Control features 
(procedure? obj) procedure 


Returns #t if obj is a procedure, otherwise returns #f. 


(procedure? car) => #t 

(procedure? ’car) = #f 

(procedure? (lambda (x) (* x x))) 
= ~=#t 


(procedure? ’(lambda (x) (* x x))) 
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(apply proc args) procedure 
The apply procedure calls proc with the elements of the list 
args as the actual arguments. 


(apply + ’(3 4)) => 7 


(define compose 
(lambda (f g) 
(lambda args 

(f (apply g args))))) 


((compose - *) 3 4) = -12 


6.7. Input and output 


Pico Scheme allows output to a character device. Input is not 
specified in this report but an implementation may be extended 
to support input. Since expressions are side-effect free, standard 
Pico Scheme programs should not perform input or output from 
expressions and implementations may require that input or out- 
put from them is an error. Output is only required to be allowed 
at the outermost level of a program. 

Rationale: Implementations may choose to allow input and output 
(IO) from expressions (like R’RS allows) or choose to forbid it. An 
implementation that forbids IO side-effects in expressions but wishes 
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to allow IO in places besides the outermost level would likely need to 
extend Scheme in a way that is not compatible with R’RS. 

For example, an implementation could add a command type that al- 
lowed IO, and syntax to create it and then allow (define displayline 
(delta (x) (display x) (newline))) to define a new command 
displayline. 

Implementations could add a non-expression do that allows IO inside 
it, similar to R’RS’s do to support more flexible IO while remaining 
a subset of R’RS. 

Besides display and newline, implementations could add write-u8, 
(define (indentifier) (read)), and (define (identifier) (read-u8) ) 
to the outermost level to support more IO. Other IO from R’RS can 
be added if string, char or port types are added. 


6.7.1. Output 


(display obj) input or output 


Writes a representation of 067 to the textual output. For booleans, 
nulls, numbers and symbols, and pairs containing these, this 
should be an external representation of the object. Returns an 
unspecified value. 


(newline) input or output 


Writes an end of line to textual output. Exactly how this is 
done differs from one operating system to another. Returns an 
unspecified value. 
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7. Formal syntax and semantics 
This chapter provides formal descriptions of what has already 
been described informally in previous chapters of this report. 


7.1. Formal syntax 


This section provides a formal syntax for Scheme written in an 
extended BNF. 

All spaces in the grammar are for legibility. Case is significant in 
the definition of (letter); for example, foo and Foo are distinct. 
(empty) stands for the empty string. 

The following extensions to BNF are used to make the descrip- 
tion more concise: (thing)* means zero or more occurrences of 
(thing); and (thing)* means at least one (thing). 


7.1.1. Lexical structure 


This section describes how individual tokens (identifiers, num- 
bers, etc.) are formed from sequences of characters. The follow- 
ing sections describe how expressions and programs are formed 
from sequences of tokens. 

Identifiers are terminated by a (delimiter) or by the end of the 
input. So are numbers and booleans. 

The following ten characters from the ASCII repertoire are re- 
served for future extensions to the language or are used in R’RS: 
Bede ke gee il Ae 

In addition to the identifier characters of the ASCII repertoire 
specified below, Scheme implementations may permit any addi- 
tional repertoire of Unicode characters to be employed in iden- 
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tifiers, provided that each such character has a Unicode general 
category of Lu, Ll, Lt, Lm, Lo, Mn, Mc, Me, Nd, Nl, No, Pd, Pe, 
Po, Sc, Sm, Sk, So, or Co, or is U+200C or U+200D (the zero- 
width non-joiner and joiner, respectively, which are needed for 
correct spelling in Persian, Hindi, and other languages). How- 
ever, it is an error for the first character to have a general cate- 
gory of Nd, Mc, or Me. It is also an error to use a non-Unicode 
character in symbols or identifiers. 


(token) —+ (identifier) | (boolean) | (number) 
GIS he 

(delimiter) —+ (whitespace) | (| ) | ; 

(intraline whitespace) —> (space or tab) 

(whitespace) —+ (intraline whitespace) | (line ending) 

(line ending) —> (newline) | (return) (newline) 
| (return) 

(comment) —+> ; (all subsequent characters up to a 

line ending) 


(identifier) —> (initial) (subsequent) * 
(peculiar identifier) 
(initial) —> (letter) | (special initial) 


(letter) —> a] b|c]...|z 
A|B|C|... |Z 

(special initial) —> !|$|%|/&|*|/]: | <|= 
Pl oe ace | 


(subsequent) —> (initial) | (digit) 
(special subsequent) 


48 Pico Revised’? Scheme 


digit) + 0]/1|2|3]4|]5|6|7|8]|9 

explicit sign) —> + | - 

special subsequent) —+ (explicit sign) | . 

peculiar identifier) —> (explicit sign) 
| (explicit sign) (sign subsequent) (subsequent)* 
| (explicit sign) . (dot subsequent) (subsequent)* 
| . (dot subsequent) (subsequent) * 

(dot subsequent) —> (sign subsequent) | . 

(sign subsequent) —+ (initial) | (explicit sign) 


( 
( 
( 
( 


(boolean) —> #t | #£ 


(number) —> (sign) (digit) + 


(sign) —> (empty) | + | - 


7.1.2. External representations 


(Datum) is what Pico Scheme successfully parses. Note that 
any string that parses as an (expression) will also parse as a 
(datum). 


(datum) —+ (simple datum) | (compound datum) 
(simple datum) —> (boolean) | (number) 
| (symbol) 
(symbol) —> (identifier) 
(compound datum) —> (list) | (abbreviation) 
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(list) —+ ((datum)*) | ((datum)t . (datum)) 
(abbreviation) —> ’ (datum) 


7.1.3. Expressions 


The definitions in this and the following subsections assume that 
all the syntax keywords defined in this report have not been 
redefined or shadowed. 


(expression) —> (identifier) 
| (literal) 

procedure call) 

lambda expression) 

conditional) 

derived expression) 


a a ae 


(literal) —>+ (quotation) | (self-evaluating) 
(self-evaluating) —+ (boolean) | (number) 
(quotation) —> ’(datum) | (quote (datum)) 
(procedure call) —+ (operator) (operand)*) 
(operator) —+ (expression) 

(operand) —+ (expression) 

(lambda expression) —+ (lambda (formals) (body)) 
(formals) —+ ((identifier)*) | (identifier) 

(body) —+ (definition)* (expression) 


(conditional) —> (if (test) (consequent) (alternate) ) 
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(test) + (expression) 
(consequent) —> (expression) 
(alternate) —> (expression) | (empty) 


(derived expression) —> 
(cond (cond clause)*) 
| (cond (cond clause)* (else (expression) )) 
| (and (test)*) 
| Cor (test)*) 
| (let ((binding spec)*) (body)) 


(cond clause) —> ((test) (expression) ) 
(binding spec) —> ((identifier) (expression) ) 


7.1.4. Programs and definitions 


(program) —> 
(expression or definition or io)t 
(expression or definition or io) —> (expression) 
| (definition) | (io) 
(definition) —+ (define (identifier) (expression) ) 
io) —+ (display (expression)) | (newline) 
play 


7.2. Formal semantics 


This section provides a formal denotational semantics for the 
primitive expressions of Scheme and selected built-in proce- 
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dures. The concepts and notation used here are described in [23] 
and [16]. The notation is summarized below: 


(ows) sequence formation 

sk kth member of the sequence s (1-based) 
#s length of sequence s 

s§t concatenation of sequences s and t 

stk drop the first / members of sequence s 
t—a,b McCarthy conditional “if t then a else b” 
pla /*| substitution “p with « for 7” 

x in D injection of x into domain D 

x|D projection of x to domain D 


The definition of K is omitted because an accurate definition of 
K would complicate the semantics without being very interest- 
ing. 


7.2.1. Abstract syntax 


K € Con constants, including quotations 
Ie Ide identifiers (variables) 

E ¢ Exp expressions 

A € Dec declarations 


Exp — K | I] (Eo E*) 

| (lambda (I*) A* Ep) 

| (lambda I A* Eo) 

| (if Eo Ey Eg) | (if Ep E,) 
Dec — (define I Eo) 
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7.2.2. Domain equations 


T = {false, true} booleans 
Q symbols 
R numbers 
Ep =EXE pairs 
M = (false, true, null, undefined, unspecified} 
miscellaneous 
oeF =E* SE procedure values 


©ecE =Q+R+E,+M+F 
expressed values 
peu =Ide>E environments 
Xx errors 


7.2.3. Semantic functions 
K:Con-E 
E:Exp>uU-E 

D:Dec> UU 


Definition of K deliberately omitted. 
E[K] = Ap. K[K] 


E[I] = Ap. (Ae. € = undefined > 
wrong “undefined variable” , 
€)(lookup p 1) 


E[(Eo E*)] = 
Ap. (Ace*.€ € F > ee*, 
wrong “bad procedure” )((E[Eo]/) 
ELE]*(0)) 
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E[Qambda (I*) A* Eo)] = 
Ap. (Ac*. #e* = #1* @ 
(E|_Eo]) (tiedecs (extends p I* €*) 
DIA“), 
wrong “wrong number of arguments” ) 
E[Qambda I A* Eo)] = 
Ap . (Ae* . (EEo]) (tiedecs (p[(e*) /T]) 
D[A*)) 
Ef Cif Eo Ey E2)] — 
Ap. truish E[Eo]p > E[E:]p, E[E2]e 
E[ Gif Eo Ei)] = 
Ap. truishE[Eo]p > E[Ei]p, unspecified 


D|(define I Eo)] = 
Ap. pi(Ae.€€F > Y(AL. ), €)(E[Eo])/T] 


7.2.4. Auxiliary functions 


lookup : U + Ide > E 
lookup = Apl. pl 


wrong: X—? [implementation-dependent] 


extends : U + Ide* > E* > U 
extends = 

Apl*a* . #1* = 0-5 p, 

extends (pl(a* 4 1)/(* 4 1) (+1) (@* t1) 

tiedecs : U > Dec* > U 
tiedecs = 

Apw* .#Y* =0— p, 

tiedecs ((¥* 4 1)p) (W*t 1) 
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truish : E— T 
truish = re. € = false > false, true 


Y:F4F 


Y= (AC) (AA) FAMAA) (AT) - (FAI*))))) 


onearg : (E > E) > (E* + E) 
onearg = 
ACe* . #e*¥ = 1 > C(e* J 1), 


wrong “wrong number of arguments” 


twoarg : (E> EE) > (E* > E) 
twoarg = 
AGe* . #e*¥ = 2 > C(e* | 1)(e* J 2), 


wrong “wrong number of arguments” 


7.2.5. Selected Environment functions 


cons: E* +E 
cons = twoarg(A€1€2 . (€1, €2) in Ep) 


car: EX >E 
car = onearg(Ae.€ € Ep > €|E,p J 1, 
wrong “non-pair argument to car”) 


cdr: EX +E 
cdr = onearg(Ae.€ € Ep > €| Ep J 2, 
wrong “non-pair argument to cdr”) 
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equ: E* SE 
equ = 

twoarg (Ae1e2 . (€1 EMA €2 EM) @ 
(ce, |M=e2|M— true, false), 
(61 €QA€2€Q) > 
(e1 |Q = e2|Q— true, false), 
(ey ERA €2 €R) > 
(ce. |R = €2|R — true, false), 
(€1 € Ep A €2 € Ep) > unspecified, 
(e. €F A €g €F) > unspecified, 


false ) 


7.3. Derived expression types 


This section gives rewrite rules for the derived expression types. By 
the application of these rules, any expression can be reduced to a 
semantically equivalent expression in which only the primitive ex- 
pression types (literal, variable, call, lambda, if) occur. 


(cond (test) (expression) ) 
(clausez) ...) 
= (if (test) 
((expression) ) 
(cond (clausez) ...)) 


(cond (else (expression) ) ) 
= ((expression) ) 


(cond) 
= (some expression returning an unspecified value) 
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(and) = #t 
(and (test) ) = (test) 
(and (testi) (teste) ...) 


= (if (test,) (and (test2) ...) #£) 


(or) #f 
(or (test)) (test) 
(or (testi) (test2) ...) 
= (if (testi) (testi) (or (teste) ...)) 


(let (((variable1) (initi)) ...) 
(body)) 


= ((lambda ((variable;) ...) (body)) (inity) ... 
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EXAMPLES 


Here are examples using Pico Scheme. 


(define list (lambda 1 1)) 
(list ’a ’b ’c) = (ab c) 


(define list? (lambda (1) 
(cond ((null? 1) #t) 
((not (pair? 1)) #£) 
(else (list? (cdr 1)))))) 
(list? ?(a b c)) = #t 
(list? ?(a . b)) = #f 


Returns a list consisting of the elements of | followed by t 


(define append (lambda (1 t) 
(cond ((null? 1) t) 


(else 
(cons (car 1) (append (cdr 1) t)))))) 
(append ’() ’(a)) = (a) 
(append ’(a b) ’(c d)) = (abc d) 


This procedure returns the first sublist of | whose car is 0bj. 


(define assv (lambda (obj 1) 
(cond ((null? 1) #£) 
(Ceqv? obj (car (car 1))) (car 1)) 
(else (assv obj (cdr 1)))))) 
(define e ’((a 1) (b 2) (c 3))) 
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(assv ’a e) = (a 1) 
(assv ’b e) => (b 2) 
(assv ’d e) => #f 
(assv 5 ?((2 3) (5 7) (11 13))) 

= (5 7) 


This shows using the Y combinator to create a recursive function. 


(let ((Y (lambda (phi) 
((lambda (f) (f f)) 
(lambda (f) 
(phi (lambda x (apply (f f) x)))))))) 
(let ((fact 
(Y (lambda (fact) 
(lambda (n) 
(if (< n 2) 1 
(* n (fact (- n 1))))))))) 
(fact 5))) => 120 


[1] 
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procedure?, 


proper tail recursion, 
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